Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a new flow to request for accountInfo by name from a particular host #94

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nitesh7sid
Copy link

As a CorDapp developer I would like to use a built-in flow from the library that can help me to fetch account details from a particular host by name and not by UUID.
If that particular host doesn't have an account created then it should return null.

Use-case: In some situations a node might have obtained account name (may be from front-end app or some offline channel) and wishes to fetch account Info details by passing that name to the host. If the account exists on that host then it should return the accountInfo else return null. e.g. a company creates account of its employee by using SSN/NIN or employee_id as account name and another company can request for accountInfo by passing account name for background-check.

@InitiatingFlow
class RequestAccountInfoByName(private val accountName: String, val host: Party) : FlowLogic<AccountInfo?>() {
@Suspendable
override fun call(): AccountInfo? {
Copy link

@adelrustum adelrustum Apr 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If ourIdentity == host, then just fetch the account from the current node.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comments.
This flow is specifically to request accountInfo from another node and not from the caller's local node itself. The assumption here is that the caller is aware that an account with name "charlie" exists on host node "Alice". (obviously the caller will try to search for account with name "Charlie" on its local vault first)

Copy link

@adelrustum adelrustum Apr 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my humble opinion, you cannot assume how your flow will be used; your code should take care of all cases.

For instance, in the RequestKeyForAccountFlow (which comes with the library):

  1. The flow returns the key immediately if the host is the initiator (see here)
  2. Otherwise, it contacts the host node (see here)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the design of this flow is kept in consistent with the design of RequestAccountInfoFlow (here)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see; now I'm curious why they did it that way 🙂

*/
class RequestAccountInfoByNameFlow(private val accountName: String, val host: FlowSession) : FlowLogic<AccountInfo?>() {
@Suspendable
override fun call(): AccountInfo? {
Copy link

@adelrustum adelrustum Apr 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If host.counterParty == ourIdentity, then just fetch the account from the current node.

@roastario
Copy link
Contributor

Hmmm - what is to stop a "malicious" node from spamming lots of requests by name. This could potentially lead to situations where data is leaked.

The purpose of using the UUID was to make it impossible to guess names.

@roger-that-dev
Copy link

roger-that-dev commented Apr 17, 2020

I'm not sure we should add this as a standard feature as it potentially leaks info about account holders. I think it's OK to look-up account holders by hash / UUID but by name is probably too much. Imagine a node being spammed with requests to figure out if some person/entity has an account there. I guess this depends actually how the account name property is used but we cannot assume it won't be a company or person name as the property is just a String. Edit: Ah just seen @roastario got here first!

@nitesh7sid
Copy link
Author

Hmm that makes sense.. Just thinking out loud here slightly on a diff context- a node can be even spammed and attacked with requests to provide new public key(s) for an account by invoking RequestKeyForAccountFlow, right? Probably there wont be any leakage issue here but the host will keep generating new keys, register into vault and probably waste its resources? Correct me if I am wrong, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants